昨天我們完成了完整的 PRD 和技術規劃，今天要進入一個關鍵階段：把 PRD 拆解成可執行的 User Stories。
這個步驟在傳統開發中常常被輕視，結果就是：
但在 AI-DLC Sprint 中，User Story 不只是需求描述，更是測試案例的設計藍圖。
今天我要做的事：
傳統做法：
PM：「我們要做一個需求輸入功能」
開發：「好，我知道了」（然後就開始寫 code）
三天後...
PM：「欸，這不是我要的」
開發：「可是你說要做需求輸入啊」
PM：「我是說要有 AI 提問功能」
開發：「......你沒講啊」
AI-DLC Sprint 做法：
PRD 寫清楚 → AI BA 拆 User Story → 定義 AC → 轉成測試案例 → 寫 code
這樣一來：
- PM 和開發者看同一份文件
- AC 就是驗收標準
- 測試案例自動生成
- 不會做錯方向
經過前三個專案，我發現好的 User Story 有三大價值：
1. 溝通語言
2. AI 的輸入
3. TDD 的基礎
我又創建了一個 Subagent，這次是「BA 專家」：
你是一位資深的 Business Analyst，專門拆解產品需求。
任務：
1. 讀取 docs/PRD.md
2. 把 PRD 中的功能拆解成 User Stories
3. 每個 Story 都要符合 INVEST 原則
4. 為每個 Story 定義 Acceptance Criteria
5. 估算 Story Points（以 Fibonacci 數列）
6. 輸出到 docs/USER_STORIES.md
User Story 格式：
As a [角色]
I want to [行為]
So that [價值]
AC 格式：
Given [前置條件]
When [執行動作]
Then [預期結果]
And [額外驗證]
AI BA 從 PRD 中識別出了幾個關鍵流程：
然後針對每個流程拆解出具體的 User Stories。
AI 一共拆出了 12 個 User Stories，我挑幾個代表性的來說明。
As a 產品負責人
I want to 用自然語言輸入我的專案想法
So that 我不需要先學會寫正式的需求文件
Story Points: 3
Priority: P0 (Must Have)
Sprint: Day 4
為什麼這個 Story 重要？
Acceptance Criteria:
AC 1.1: 基本輸入介面
AC 1.2: 輸入驗證
AC 1.3: 提交成功
As a 產品負責人
I want to AI 主動問我問題來釐清需求
So that 我可以把模糊的想法變成清晰的需求
Story Points: 5
Priority: P0 (Must Have)
Sprint: Day 4-5
為什麼這個 Story 重要？
Acceptance Criteria:
AC 2.1: 生成澄清問題
AC 2.2: 對話式互動
AC 2.3: 完成對話
As a 開發者
I want to 一鍵創建 GitHub Repo 並同步所有文件
So that 我不需要手動建立專案結構和上傳文件
Story Points: 8
Priority: P0 (Must Have)
Sprint: Day 5-6
為什麼這個 Story 重要？
Acceptance Criteria:
AC 5.1: GitHub OAuth 整合
AC 5.2: Repo 創建
AC 5.3: 文件同步
docs/PRD.md
docs/USER_STORIES.md
AC 5.4: Issue 創建
AI 生成的 Stories 很不錯，但我還是要用 INVEST 原則檢查一遍。
這是好 User Story 的六大特質：
我發現幾個問題：
問題 1：Story #4（自動拆解 User Stories）太大了
原本的 Story Points 是 8，代表需要一整天，這違反了 Small 原則。
調整方案： 拆成兩個 Story
Story #4a: 基本拆解功能（5 points）
Story #4b: Story 編輯功能（3 points）
問題 2：Story #2 和 Story #3 有依賴關係
Story #2（AI 提問）和 Story #3（生成 PRD）其實是連續的流程，違反了 Independent 原則。
調整方案： 不拆開，而是在規劃時連續排程
問題 3：有些 AC 不夠明確
例如 Story #2 的 AC 2.1 說「顯示 3-5 個問題」，但沒說問題的品質標準是什麼。
調整方案： 補充細節
Story Points 對應時間：
調整後，12 個 Stories 的分布：
基於前三個專案的經驗，我知道一天實際開發時間大約是 6-8 小時（扣掉測試、Debug、休息）。
Day 4（環境設定 + 基礎功能）
Day 5（核心 AI 功能）
Day 6（PRD 完成 + Story 拆解）
Day 7（GitHub 整合準備）
Day 8（GitHub 整合完成）
Day 9（收尾與部署）
如果開發過程中發現時間不夠，有三個調整選項：
Option 1：降級 Story #4b
Option 2：簡化 Story #5
Option 3：砍掉 P1 功能
最小可行版本（MVP）：
這個版本就足以驗證 BoltHQ 的核心價值了。
今天規劃 Stories 時，我一直在想：這些 AC 明天要怎麼變成測試？
以 Story #1 的 AC 1.2 為例：
AC 寫法：
Given 我在輸入框中
When 我輸入少於 20 字
Then 系統顯示警告
And 提交按鈕保持禁用
對應的測試案例：
describe('AC 1.2: 輸入驗證', () => {
it('輸入少於 20 字應該顯示警告', async () => {
// Given: 在輸入框中
render(<ProjectInput />);
const input = screen.getByRole('textbox');
// When: 輸入少於 20 字
await userEvent.type(input, 'short text');
// Then: 顯示警告
expect(screen.getByText(/請至少描述 20 字/)).toBeInTheDocument();
// And: 提交按鈕禁用
const submitButton = screen.getByRole('button', { name: /開始分析/ });
expect(submitButton).toBeDisabled();
});
});
關鍵發現：
明天開始開發時，我會這樣做：
1. 選一個 Story（例如 Story #1）
Story #1: 輸入專案需求（3 points）
2. 從第一個 AC 開始寫測試
// AC 1.1 的測試
describe('AC 1.1: 基本輸入介面', () => {
it('應該顯示輸入框', () => {
// 測試會失敗（紅燈），因為組件還不存在
});
});
3. 請 AI 生成最少的 code 讓測試通過
// AI 生成的組件
export function ProjectInput() {
return <textarea />;
}
4. 執行測試，確認通過（綠燈）
✓ 應該顯示輸入框
5. 重構和優化
// 重構：加上樣式、prop types
export function ProjectInput({ placeholder }: Props) {
return (
<textarea
className="w-full min-h-[200px]"
placeholder={placeholder}
/>
);
}
6. 繼續下一個 AC
AC 1.2 → AC 1.3 → Story #2...
這個循環就是 TDD 的紅綠燈循環，也是我在前三個專案驗證有效的流程。
今天最大的收穫是理解了 User Story 的真正價值。
「Story 就是寫給 PM 看的，開發者看 code 就好」
結果：做到一半才發現理解錯誤，返工
「Story 是整個團隊的共同語言」
- PM 用它確認需求
- 開發者用它寫測試
- 測試人員用它驗收
- AI 用它生成 code
結果：所有人都在同一個頁面上
一份文件，多種用途
PRD → User Stories → AC → 測試案例 → 實作
不是四份文件，而是一條線
AI 可以理解，人也可以理解
這就是 Spec-Driven Development 的威力
iThome鐵人賽
看影片追技術